Issue # (if applicable)
Closes #34018.

Reason for this change

AWS customers deploying multi-account infrastructure often need to assume cross-account roles for AwsCustomResource operations. However, without proper security measures, this can lead to "confused deputy" attacks where a malicious actor tricks the service into performing actions on behalf of a different account.

External IDs are a security best practice recommended by AWS to prevent these attacks by requiring an additional secret value when assuming cross-account roles. Currently, AwsCustomResource supports assumedRoleArn but lacks the externalId parameter, forcing customers to choose between cross-account functionality and security best practices.

Description of changes

This change adds External ID support to AwsCustomResource to enable secure cross-account role assumptions:

Core Interface Changes:

Added optional externalId property to the AwsSdkCall interface in aws-custom-resource.ts
Enhanced the interface with comprehensive documentation explaining security benefits and usage patterns
Lambda Handler Implementation:

Modified utils.ts in custom-resource-handlers to pass External ID to STS AssumeRole calls
Updated construct-types.ts interface to maintain type safety between CDK construct and Lambda handler
Enhanced getCredentials function to include ExternalId parameter when provided
Security Features:

External ID support for all lifecycle operations (onCreate, onUpdate, onDelete)
Different external IDs can be specified for different operations
Maintains full backward compatibility - external ID is optional
Works seamlessly with existing assumedRoleArn and region configurations
Documentation and Examples:

Added comprehensive README section explaining External ID security benefits
Included practical examples for single and per-operation external ID usage
Added links to AWS IAM documentation for security best practices
Documented integration with cross-account scenarios
Design Decisions:

Made externalId an optional property to maintain backward compatibility
Follows existing pattern used by assumedRoleArn for consistency
External ID is only used when assumedRoleArn is specified
Enables different external IDs per operation for fine-grained security control
Alternatives Considered and Rejected:

Separate construct: Would fragment the API and require maintaining two similar constructs
Global external ID configuration: Less secure and flexible than per-operation configuration
Required external ID: Would break backward compatibility for existing users
Describe any new or updated permissions being added
No new IAM permissions are required for this feature. The External ID is a security parameter used during the existing STS AssumeRole operation and does not require additional permissions.

The feature works within the existing permission model:

The Lambda function still uses its existing IAM role
The assumedRoleArn role requires the same permissions as before
External ID is validated by STS as part of the standard AssumeRole process
No additional AWS service calls or permissions are needed
Description of how you validated changes

Unit Testing (10 comprehensive test cases):

External ID parameter passing through to CloudFormation template
Different external IDs for different lifecycle operations
Backward compatibility when external ID is not specified
Integration with existing assumedRoleArn functionality
CloudFormation template generation with correct parameters
Edge cases and error handling scenarios
Integration Tests (4 real-world scenarios):

Cross-account role assumption with external ID
STS GetCallerIdentity operation with external ID validation
Integration test with proper CDK snapshot validation
End-to-end workflow demonstrating security enhancement
Lambda Handler Tests (7 utility function tests):

getCredentials function correctly passes External ID to STS
AssumeRole call includes ExternalId parameter when provided
Backward compatibility when external ID is not specified
Type safety between construct interface and Lambda implementation

Manual Testing:

Deployed test stack with cross-account External ID configuration
Verified STS AssumeRole calls include External ID parameter
Confirmed prevention of confused deputy attack scenarios
Validated integration with existing AWS CDK patterns
Security Validation:

Reviewed AWS security documentation alignment
Tested confused deputy attack prevention
Validated with enterprise multi-account use cases

Checklist

• My code adheres to the CONTRIBUTING GUIDE and DESIGN GUIDELINES
• Added comprehensive unit tests for all new functionality
• Added integration tests demonstrating real-world usage
• Updated documentation with usage examples
• Ensured backward compatibility with existing code
• Included proper asset hash invalidation
• Followed existing AWS CDK patterns and conventions
• No breaking changes introduced

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license